GCD源码分析2 —— dispatch_once篇

前言

这篇文章主要分析一下dispatch_once的底层实现,相对而言,这应该是GCD源码分析系列中最简单的一篇了。

dispatch_once分析

在iOS开发中,我们经常使用dispatch_once去定义一个单例,来保证对象的唯一性,不过我们是否去了解过dispatch_once是如何在多线程情况下保证生成对象的唯一性呢?例如,我们经常用下面的代码块生成一个单例。

1
2
3
4
5
6
7
8
+ (instancetype)sharedInstance {
static XXObject *_instance;
static dispatch_once_t _predicate;
dispatch_once(&_predicate, ^{
_instance = [[XXObject alloc] init];
});
return _instance;
}

这段代码中涉及到两个关键词,一个是dispatch_once_t,一个是dispatch_once,下面我们逐个分析

dispatch_once_t

在once.h中找到其定义如下:

1
typedef long dispatch_once_t;

dispatch_once_t原来是一个长整型!真是让人措手不及…

dispatch_once

1
2
3
4
void dispatch_once(dispatch_once_t *val, void (^block)(void)){
struct Block_basic *bb = (void *)block;
dispatch_once_f(val, block, (void *)bb->Block_invoke);
}

可以看到,在dispatch_once中,生成一个Block_basic指针,指向了block,并把其Block_invoke函数指针传递给了dispatch_once_f
相信大家一定有疑问,Block_basicBlock_invoke是什么东西?很遗憾,源码中找不到,我们可以推测一下:

  • Block_basic首先是一个结构体,它定义的指针可以指向void (^block)(void)类型的block
  • Block_invoke的字面意思是触发一个block,可以参考以下代码理解
1
2
3
4
5
6
void _dispatch_call_block_and_release(void *block)
{
void (^b)(void) = block;
b();
Block_release(b);
}

接下来分析核心函数dispatch_once_f

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
void dispatch_once_f(dispatch_once_t *val, void *ctxt, void (*func)(void *)){

volatile long *vval = val;
if (dispatch_atomic_cmpxchg(val, 0l, 1l)) {
func(ctxt); // block真正执行
dispatch_atomic_barrier();
*val = ~0l;
}
else
{
do
{
_dispatch_hardware_pause();
} while (*vval != ~0l);
dispatch_atomic_barrier();
}
}

  • 1、在开篇中已经讲过dispatch_atomic_cmpxchg,它是一个宏定义,原型为__sync_bool_compare_and_swap((p), (o), (n)) ,这是LockFree给予CAS的一种原子操作机制,原理就是 如果p==o,那么将p设置为n,然后返回true;否则,不做任何处理返回false

  • 2、在多线程环境中,如果某一个线程A首次进入dispatch_once_f,*val==0,这个时候直接将其原子操作设为1,然后执行传入dispatch_once_f的block,然后调用dispatch_atomic_barrier,最后将*val的值修改为~0。

  • 3、dispatch_atomic_barrier是一种内存屏障,所谓内存屏障,从处理器角度来说,是用来串行化读写操作的,从软件角度来讲,就是用来解决顺序一致性问题的。编译器不是要打乱代码执行顺序吗,处理器不是要乱序执行吗,你插入一个内存屏障,就相当于告诉编译器,屏障前后的指令顺序不能颠倒,告诉处理器,只有等屏障前的指令执行完了,屏障后的指令才能开始执行。所以这里dispatch_atomic_barrier能保证只有在block执行完毕后才能修改*val的值。

  • 4、在首个线程A执行block的过程中,如果其它的线程也进入dispatch_once_f,那么这个时候if的原子判断一定是返回false,于是走到了else分支,于是执行了do~while循环,其中调用了_dispatch_hardware_pause,这有助于提高性能和节省CPU耗电,pause就像nop,干的事情就是延迟空等的事情。直到首个线程已经将block执行完毕且将*val修改为~0,调用dispatch_atomic_barrier后退出。这么看来其它的线程是无法执行block的,这就保证了在dispatch_once_f的block的执行的唯一性,生成的单例也是唯一的。

dispatch_once死锁(更新模块)

上面说了这么多,是不是说使用dispatch_once写单例就可以高枕无忧了呢?
实际上并非如此,不正当地使用dispatch_once可能会造成死锁:

  • 死锁方式1:
    1、某线程T1()调用单例A,且为应用生命周期内首次调用,需要使用dispatch_once(&token, block())初始化单例。
    2、上述block()中的某个函数调用了dispatch_sync_safe,同步在T2线程执行代码
    3、T2线程正在执行的某个函数需要调用到单例A,将会再次调用dispatch_once。
    4、这样T1线程在等block执行完毕,它在等待T2线程执行完毕,而T2线程在等待T1线程的dispatch_once执行完毕,造成了相互等待,故而死锁

  • 死锁方式2:
    1、某线程T1()调用单例A,且为应用生命周期内首次调用,需要使用dispatch_once(&token, block())初始化单例;
    2、block中可能掉用到了B流程,B流程又调用了C流程,C流程可能调用到了单例A,将会再次调用dispatch_once;
    3、这样又造成了相互等待。

所以在使用写单例时要注意:

  • 1、初始化要尽量简单,不要太复杂;
  • 2、尽量能保持自给自足,减少对别的模块或者类的依赖;
  • 3、单例尽量考虑使用场景,不要随意实现单例,否则这些单例一旦初始化就会一直占着资源不能释放,造成大量的资源浪费。

dispatch_once写单例的省力姿势

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
#ifdef __has_feature(objc_arc) 

#define singleton_h +(instancetype)sharedInstance;

#define singleton_m static id _instanceType = nil;\
+(instancetype)sharedInstance\
{\
static dispatch_once_t onceToken;\
dispatch_once(&onceToken, ^{\
_instanceType = [[self alloc]init];\
});\
return _instanceType;\
}\
+ (instancetype)allocWithZone:(struct _NSZone *)zone\
{\
static dispatch_once_t onceToken;\
dispatch_once(&onceToken, ^{\
_instanceType = [super allocWithZone:zone];\
});\
return _instanceType;\
}\
-(id)copyWithZone:(NSZone *)zone\
{\
return _instanceType;\
}

#else

#define singleton_h +(instancetype)sharedInstance;

#define singleton_m static id _instanceType = nil;\
+(instancetype)sharedInstance\
{\
static dispatch_once_t onceToken;\
dispatch_once(&onceToken, ^{\
_instanceType = [[self alloc]init];\
});\
return _instanceType;\
}\
+ (instancetype)allocWithZone:(struct _NSZone *)zone\
{\
static dispatch_once_t onceToken;\
dispatch_once(&onceToken, ^{\
_instanceType = [super allocWithZone:zone];\
});\
return _instanceType;\
}\
-(id)copyWithZone:(NSZone *)zone\
{\
return _instanceType;\
}\
-(oneway void)release\
{\
\
}\
-(instancetype)retain\
{\
return _instanceType;\
}\
-(instancetype)autorelease\
{\
return _instanceType;\
}\
- (NSUInteger)retainCount\
{\
return 1;\
}

#endif

然后在要实现的单例.h文件中添加singleton_h,.m文件中添加singleton_m即可

总结

dispatch_once的分析是最简单的,这也意味着后续系列的的分析将逐渐变得复杂,等待猛烈的暴风雨吧!

-------------本文结束 感谢您的阅读-------------

本文标题:GCD源码分析2 —— dispatch_once篇

文章作者:lingyun

发布时间:2018年02月01日 - 21:02

最后更新:2018年10月17日 - 23:10

原始链接:https://tsuijunxi.github.io/2018/02/01/GCD源码分析2 —— dispatch-once篇/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

坚持原创技术分享,您的支持将鼓励我继续创作!

本文标题:GCD源码分析2 —— dispatch_once篇

文章作者:lingyun

发布时间:2018年02月01日 - 21:02

最后更新:2018年10月17日 - 23:10

原始链接:https://tsuijunxi.github.io/2018/02/01/GCD源码分析2 —— dispatch-once篇/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。